Pure-julia OpenAPI internals rewrite - #103

Thanks @quinnj . I did some trials with the new client. Majority of the specs that I tried work fine. But here are a few things which I feel should be addressed:

• The response code declaration in spec seems too strict. Specs sometimes do not document response code when they do not return any data. With the new client, this throws an error.
• Missing Content-Type on a response would throw exception. The existing client deserializes by status alone. The new client throws UnexpectedContentType. Sloppy servers, which we do encounter in practice, would become client errors.
• Date time fields do not support time zone.
• Streaming support is not there

I will also try this out with some more complicated specs, maybe the k8s api spec.

Thanks for the thorough trial run, @tanmaykm — all four points are addressed as of ac0689d:

Undocumented response codes no longer error. A 2XX status the spec doesn't describe now succeeds: an empty body returns nothing, a non-empty body returns the raw bytes. Undocumented error statuses still throw ApiError (with the raw body attached) so failures stay visible.

Missing/misreported Content-Type falls back to decoding by status. When a response has no Content-Type, or misreports it while only one media type is documented for that status, the client decodes with the documented media type — the legacy "deserialize by status alone" behavior. UnexpectedContentType is now reserved for the genuinely ambiguous case: several documented media types and a header that matches none of them.

Time zones. Offsets like 2020-01-02T03:04:05+05:30 parse in the default Dates.DateTime mapping by normalizing to UTC (and zone-less date-times are accepted as UTC). For preserved offsets, generate with OpenAPI.client(doc; datetime = :zoned): format: date-time fields then map to TimeZones.ZonedDateTime with RFC 3339 round-tripping, matching the legacy client's ZonedDateTime behavior. The default stays DateTime so plain clients keep no TimeZones dependency (and stay juliac --trim friendly); the option is a one-liner where zone fidelity matters.

Streaming responses. Every generated operation now accepts stream_to = Channel(n). The call returns at the response head and a background task decodes items onto the channel: application/json bodies split into consecutive JSON documents each decoded against the documented schema (the k8s watch convention), JSON Lines/NDJSON decode per line to the array's element type, JSON text sequences split on RFC 7464 records, text/* yields lines, and other media yield raw chunks. Decode/validation failures close the channel with the error, error statuses throw ApiError with the buffered body, and closing the channel from the consumer side aborts the transfer (connection torn down, not leaked).

events = Channel{Any}(16)
K8sClient.watch_core_v1_namespaced_pod(...; stream_to = events)
for event in events
    ...
end

Test coverage added for all of the above, including a raw chunked-transfer fixture that splits items across wire chunks.

I also pre-flighted the k8s trial you mentioned: the v3 documents pair application/json with application/json;stream=watch on every list operation, and the normalizer was rejecting those as case-insensitive duplicate media types. Parameterized keys are now kept distinct, and the core api/v1 document (112 paths, all the watch operations) generates and compiles cleanly. Would still very much appreciate your run against the rest of the k8s groups.

[update prompted and reviewed by quinnj, posted by claude]